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(57) A method of network managing comprises 
steps of providing a plurality of network nxxJules execut- 
ing a distributed application; and providing a single 
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Description 

Field of the Invention 

[0001 ] This invention relates to a method of networl< 5 
managing and more particularly to a method of network 
managing by providing a plurality of network nrKxIules in 
a system which allocates management functions 
among different modules in a network chassis. 

10 

Background of the Invention 

[0002] A computer network management system 
typically provides one or more of the following functions: 
. monitoring acgvltyjpn^^ is 
erating alarms and/or isolating faults, allocating network 
resources, directing traffic, and determining or reconfig- 
uring the network topology. As the complexity of compu- 
ter networks increases, there is a growing need for 
inproved management systems. In particular, there are so 
concerns about a total or partial system "crash** (i.e., 
loss of network function) caused by a malfunction in the 
management system, the transmission and processing 
"delays -and- r^uetiof^in-memoryspace-caused-by-the 
management operations themselves, and the inabiHty to 26 
expand the network and/or major expense of replacing 
or upgrading the management system to accommodate 
a larger network 

[0003] In one prior art system, all management 
functions are provided on one module ("the manage- so 

ment module") which is plugged into the networking 
chassis. A "networking chassis" is a housing and back- 
plane which receives "networking cards" that perform 
various networking services, such as repeating, bridg- 
ing and routing. Each networking card or module 3S 
includes its own microprocessor. In this prior art system, 
the "management module" has all of the hardware and 
firmware necessary to collect, store and process all of 
the data required to manage the system. This creates a 
serious problem if there is a malfunction in the manage- 40 
ment module and It needs to be pulled, i.e., there is 
nothing left to manage the system. To guard against this 
catastrophe, the user may purchase a spare module but 
this is an expensive method of insurance. Also, even 
during normal operation, consolidating all of the man- 4S 
agement functions in one module creates a potential 
bottleneck when there is an increasing level of transmis- 
sions and/or processing. Still further, the management 
module has a defined capacity and thus there is an 
upper limit on the amount of allowable network expan- so 
sion (i.e., increase In the number of ports and/or traffic). 
- -For- this-reas0n7 -the purchaser -of the system- must 
decide whether to buy a larger management system 
than it presently needs but which will accommodate 
future expansion, or an adequate system which may ss 
have to be fully replaced if there is further expansion. 
[0004] In another prior art system, each module In 
the chassis separately manages its own functions. In 



this case the chassis is merely a "housing" containing 
independent jietworking systems,. In addition to the 
complexities of separate management, this system has 
problems similar to the "one management module" sys* 
tem in regard to the loss of network service accompany- 
ing each management malfunction, a potential 
bottleneck where eacti module must conduct its own 
management, and limited expansion capacity. 
[0005] It is an object of the present invention to pro- 
vide a new type of network management system 
wherein the system is managed "as a whole" but the 
management functions are "distributed" across the sys- 
tem. 

[0006] It is an object to provide a plurality of nodules 
in a networking ch assis wh ich together handle tiie man- 
agement functions and wherein a maffunction in one 
module will not substantially effect the functions of the 
other modules and the overall management of the net- 
work. 

[0007] Another object is to provide a system whk;h 
permits ready expansion of the network without requir- 
ing replacement of the management system. 
[0008] Another object is to provide a system which 
allows modification of the management functions with- 
out requiring replacement of the entire management 
system. 

[0009] Still another object is to provide a system 
with a better allocation of resources for management 
functions in order to provide a system with greater 
throughput. 

[0010] These and other objects of the present 
invention will be evident from the following summary 
and detailed description of select embodiments of the 
present invention. 

ggmm^ryofthe Inv^ntipn 

[0011] A distributed chassis agent ("DCA") for a 
network is provided which enables the chassis to be 
managed as a single system, and wherein any module 
can perform the management function or it can be per- 
formed by multiple modules simultaneously. The system 
scales to Increasing module complexity and number as 
it spreads its workload across the modules contained 
within the chassis, discriminating against the most used 
modules. Using this system the degree of fault tolerance 
for the management of the chassis is equal to the 
number of modules contained within the chassis, as 
each module may be capable of performing the man- 
agement function for the entire chassis. 
[0012] The management function can be per- 
formed, for-example. using the SNMP protocol which is 
part of the TCP/IP protocol suite. The management sys- 
tem Is accessed via a network address which Is known 
as the "chassis address." The management function 
may be run on one or more nxxlules within the chassis, 
but is always assessed via the same chassis address. 
[0013] Three new functions of the chassis agent 
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are: a) a discovery function conducted by each module 
to determine, store and send to the other modules infor- 
mation specific to that module, and to listen to the mes- 
sages of other modules and store similar information 
regarding the other modules; b) an election function 
conducted by each module to determine which mod- 
ule(s) should conduct a specific management function; 
and c) distributed MIBs, wherein each object in the MIB 
has an identifier (known as an OID) which is registered 
both locally (i.e., on the module on which it resides) and 
remotely (on ail other modules in the chassis) in a nam- 
ing tree (MIB) located on every module, while the data 
for each object is stored only in one module. These and 
othernew functions of the chassis agent are more fully 
described below. The chassis agent may be imple- 
mented in an object-oriented software language such 
as C++. 

[001 4] One of the benefits of the new system is that 
it can operate without synchronization of the modules. 
This avoids the problems and complexities inherent in a 
synchronized system. Thus, each module can hav$ its 
own clock and broadcast asynchronously (after a spec- 
ified announcement period of, for example, one sec- 
ond), during discovery and other functions. Each 
module will continuously receive information from the 
other modules and update its own slot table of module 
information. The system is in a continuous state of "con- 
trolled instability" such that the necessary database 
updates and allocation of management functions are 
achieved within a few clock ticks by each of the mod- 
ules. 

[0015] In order for the networking chassis to func- 
tion as a single system (i.e., in the view of the network 
and its users), the networking modules and other com- 
ponents (e.g., the power supply) within the chassis 
need to discover each other. Each module is required to 
keep track of the presence or absence of other modules 
and components within the same chassis, and of other 
operational parameters of each module/component 
Module discovery is a continuous process, with each 
module issuing on a timely basis (order of seconds) an 
unsolicited message on the backplane of the chassis. 
The message contains basic information about the 
module, such as its slot ID within the chassis, internal 
management and external data link addresses, and the 
status of various objects on the module. Each module 
uses this information to build its own slot table contain- 
ing the basic information about itself and similar infor- 
mation regarding the other modules. This information is 
used by a module to discover in which chassis it is cur- 
rently installed. Once the module Is discovered and 
entered into the slot table, the module may be polled for 
information about its resources. Each module includes 
its own processor (CPU), memory and interfaces. The 
information in the slot table compiled by each module 
may include information concerning the type, speed and 
utilization of its CPU, the type, size and consumed 
amount of its memory, and the type and speed of its 



interfaces. The information may further describe appli- 
cations on that module, such as the type of application 
(stand-alone or distributed), and its status (enable, dis- 
able, standby), Asdesaibed hereinafter, once the mod- 
5 ules have discovered one another, additional discovery 
may take place regarding the managed objects within 
the chassis's database and an election of modules \s 
made to perform each specific management applica- 
tion. 

10 [001 6] At start-up or after a system change (module 
failure/removal, etc.), an election process is required to 
discover tiie best location(s) to run a management 
application(s). The decision on where to locate an appli- 
cation-(i.e.j-which-module)-within the chassis may be 

75 based on the following: module's available resources, 
current applications, current profile (i.e.. current 
processing load), module type, and stot number. Each 
application may have Its own set of instructions for 
selecting the best location at which to be executed. The 

20 election instructions are performed by each module 
using the data found in its slot table. As each module 
has the same view of the system, each election process 
will arrive at the same result. The module selected will 
issue an unsolicited message with the new status of its 

25 application list. 

[0017] With respect to distributed MIBs. in one 
embodiment a MIB tree is maintained on every module 
with local or remote addresses (in the form of OlDs) for 
every managed object in the system, but ttie data for 

30 each object in the MIB is distributed and kept on only 
the local module (I.e., the module on which it resides). 
This saves space in that the data is not stored on every 
module. However, by registering each object botii 
locally and remotely, each module can provide a single- 

3$ point-of-access for all of the objects in the management 
system. Meanwhile, the system is fault tolerant in that 
the data for all objects Is not stored on one module. In 
an alternative embodiment, the MIB tree is provided on 
only one module,, while the data remains distributed. 

40 This system is fault tolerant in terms of the data, but 
does not provide a single-point-of-access on each mod- 
ule. 

[0018] One metiiod by which tiie present embodi- 
ment achieves fault tolerance is that faults in the mod- 

45 utes are detected by the other modules using module 
discovery Module discovery allows the modules to dis- 
cover the presence or absence of other modules in the 
chassis and their status. The system is designed to take 
advantage of the module discovery Information by 

50 dynamically reconfiguring when a module Is detected or 
lost with a minimal loss of network service. 
[0019] A further measure of fault tolerance is 
achieved by providing two backplanes for intermodule 
management communications. The module discovery 

55 messages may be sent out on both backplanes, with a 
decision being made by the receiving module to elect 
one backplane (e.g., the fastest) for further communica- 
tion with that module, until some failure necessitates a 
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new election. The ability to switch immediately to the 
alternative bacl^lane prevents a loss of network sen/- 
ices. 

[0020] These and other functions and benefits of 
the present invention will be more fully described in the s 
following detailed description. 

Brief Description off the Drawings 

[0021] 10 

Fig. 1 1s a perspective view of a networking chassis 
according to the present invention; 
Fig. 2 is a logical view of the networking chassis; 
Fig. 3 is a schematic illustration showing the net- 75 
working modules connected by two system man- 
agement buses (SMB1 and SMB10); 
Fig. 4 is a schematic illustration of packet encapsu- 
lation for transmission on SMBIO; 
Fig. 5 is a schematic illustration of intermodule dis- 20 
covery showing the transmission of module discov- 
ery messages on the SMBs and the formation of a 
slot table; 

Fig. 6 is a schematic illustration showing the local 
and remote registration of a distributed managed 25 
object on the chassis modules (entities); 
Fig. 7 is a schematic illustration showing generally 
the retrieval of a managed object (MO) in response 
to instructions received on both local and remote 
modules; and 30 
Fig. 8 is a schematic illustration similar to Fig. 7 
showing more specifically a method of retrieving a 
managed object hekJ on a local or remote module. 

Detailed Description 35 

[0022] As shown in Fig. 1 . a networking chassis 10 
is a mechanical enclosure 12 that is used to house net- 
working modules 14 such as repeater modules, bridge 
modules, terminal servers, file servers, etc. The chassis 40 
provides slots into which networking modules are 
inserted. Each module occupies one or more slots 
within the chassis. 

[0023] The chassis in addition to being a mechani- 
cal enclosure provides a backplane 16 through which 4S 
the modules inserted into the chassis are provided 
power from the chassis' power supply 18. The back- 
plane is also used to provide networking connectivity 
between modules. 

[0024] The chassis power supplies are modular so 
units that are also inserted into the chassis, either at the 
back of the chassis or underneath the chassis. The net- 
working chassis supports three types of power supplies: 

Traditional Power Supplies (AC to DC supplies) ss 
Uninterruptable Power Supplies (AC to DC/DC sup- 
plies) 

• Battery Backed Units (DC supplies) 



[0025] Logically a traditional networking chassis 
may be viewed as a collection of network service pro- 
viders connected via a common network (or networks). 
The common network (or networks) is provided by the 
chassis* backplane. Fig. 2 is a logical view of a network- 
ing chassis showing a pair of backplanes 20, 22 with 
connections to three modules 24. 26, 28, and each of 
the modules having a.series of front panel ports 25, 27, 
29, respectively 

[0026] Networking modules are microprocessor 
based (CPUs 24A. 26A. 28A in Fig. 2) and are generally 
constructed with two or more network ports; the network 
ports may appear at the front panel of the module (ports 
25. 27. 29), or may be ports that connect to the chassis 
backplane (ports 19, 21, 23). The network ports are 
used for two purposes, firstly to perform networking 
services as repeating, bridging and routing, and sec- 
ondly to provide access to the modules microprocessor 
for management purposes. Modules are traditionally 
managed using the SNMP protocol, a protocol which Is 
part of the TCP/IP protocol suite. Each module is 
required to have its own network address known as an 
IP address. Each module also has a data link address 
known as a MAC address. 

[0027] The SNMP protocol was developed by the 
IETF (Internet Engineering/ Task Force) and is specified 
in the following RFC: 

• RFC 1 1 55 Structure of Management Information 

• RFC 1 1 57 Simple Network Management Protocol 

• RFC 1212 Concise MIB definitions 

• RFC 1213 Management Information Base II (MIB- 
II) 

[0028] The apparatus of the present invention, 
hereinafter referred to as the "Distributed Chassis 
Agent" (DCA). builds upon this model using the SNMP 
process in each module but only requiring a single IP 
and MAC address for the entire chassis. Also the DCA 
allows MiBs to be distributed across all modules in the 
chassis and accessible by each module's SNMP proc- 
ess. This allows the chassis to be viewed as a single 
system for management purposes rather than a collec- 
tion of systems. The chassis and all it contains can be 
managed via a single agent who's work load is distrib- 
uted across all the modules in the chassis. The con- 
struction of the DCA is broken down into tiie following 
parts: 

1 . Intermodule Communications 

2. Discovery 

3. Chassis Election 

4. Chassis Agent Access 

5. MIB distribution. 

1 ■ Intermodule Communications 

[0029] A major component of the DCA is some form 



4 



7 



EP 1 014 621 A2 



8 



of-lntermodule communication: While-the-DCA appears 
as a single entity to the outside world, internal to the 
chassis it is a collection of programs running on a col- 
lection of modules. In order for the DCA to appear as a 
single agent the individual modules must be able to 
communicate with one another In order for this commu- 
nication to take place a common bus or network must 
be available to all the modules. In the present imple- 
mentation a common communication protocol must be 
used by all the modules. 

[0030] Intermodule communications are accom- 
plished in the present implemientation via a system 
management bus (SMB). As shown in Fig. 3, the SMB 
— 30Js-coraposed^t4wo-LANs-^ SMB10 (based on 
ETHERNET), and SMB1 (based on LOCALTALK). The 
SMB is a means of communication between networking 
modules 32-36, and also provides an "out-of-band" link 
to NMSs (Network Management Stations) and file serv- 
ers. The use of two common networks provides a level 
of fault tolerance; the SMB1 acts as a backup for the 

: SMB10, and vice-a-versa. The SMB does not perform 
any form of load sharing. The DCA only requires that 
oiie common" ne^^ More than two conv 

mon networks may be provided to gain even greater 
fault tolerance. 

: [0031] . As illustrated in Fig. 4. intermodule commu- 
nication by applications is performed using the TCP/IP 
protocol stack 40. The protocol stack allows applica- 
tions running on modules 32-36 to communicate using 
either UDP sockets or TCP sockets. Most applications 
communicating over the SMB utilize UDP sockets, 
which provide a' connectionless service. TCP provides a 
connection oriented service^ TCP and UDP sockets are 
described in any documentation for Berkeley 4BSD 
UNIX and are readily known to those skilled in the art. 
[0032] TCP and UDP run over an IP layer which 
performs the network addressing function. Each mod- 
ule/component on the SMB requires an internal IP 
address, which in this embodiment takes the following 
form: 

127.chassis id .slot, host 

[0033] Each module automatically assigns its own 
internal IP address based on its own information about 
the chassis in which It is installed, the slot it occupies 
and the number of hosts it supports. A 127.xx.xx.xx 
class A network number is used to ensure that internally 
assigned IP addresses will not clash with any external^ 
assigned IP address. IP datagrams, when encapsulated 
for transmiissibn over ether net , ' uselhe etherhet'proto^ 
col type assigned for IP protocol, namely type OSOOh. 
IP datagrams using the internally assigned addresses, 
when encapsulated for transmission over the SMB10, 
use the ethernet protocol type 81CFh. IP datagrams 
using the internally assigned addresses, when encap- 
sulated for transmission over the SMB1, use the LLAP 
protocol type 3. These protocols are described in and 



are readily known to those skilled in the art. By way off 
illustration, Fig. 4 shows (on the left) an "externally- 
addressed IP packet 42 encapsulated for ethernet, with 
SMB10 driver 44 accessing the destination address DA 

5 (43) In the header of packet 42. Fig. 4 shows on the right 
an "internally" addressed IP packet 46 encapsulated for 
ethernet. wherein the SMB1 0 driver 44 accesses the IP 
packet or data portion 47 of packet 46. 
[0034] Each module on the SMB1 0 is also assigned 

10 a data link MAC address by the module's address 
PROM. MAC addresses are globally unique and are 
assigned by the IEEE. 

[0035] Each module further assigns itself a 
LOCAUIALK address based on the slot it occupies in 
IS the chassis. 

2. Discovery 

[0036] In order for the chassis to function as a sin- 
20 gle system (i.e., to the rest of the world), the modules 
and. other conponents (e.g., the power supplies) within 
the chassis need to discover the chassis in which they 
areTnsTalled. the presence or absence of other modules 
and components within the same chassis, and other 
26 operational parameters within each module/component. 

2.1. Slot Table 

[0037] Module discovery is a continuous process. 

30 Each module on a timely basis (order of seconds) 
issues an unsolicited message on both the SMB1 net- 
work (in the form of a broadcast) and the SMB10 net- 
work (in the form of a multicast). This is illustrated in Rg. 
5 wherein a representative module 50 sends its module 

35 discovery message onto both SMB1 and SMB10, for 
receipt by the other modules 52 and 54. The message 
is an NVMP (network Variable Monitor Protocol) net- 
work variable containing basic information about mod- 
ule 50, such as: 

40 

Slot ID 

LLAP address 

MAC address 

IP address 
45 Module Type 

Chassis IP address 

Chassis MAC address 

Chassis Serial number 

SMB controller status 
50 Model CPU status 

Model CPU profile (i.e., CPU's current processing 

load) 

[0038] The above information is used to build a slot 
55 table having an entry for each of the discovered mod- 
ules. For example, in Fig. 5 a slot table 60 is shown 
which includes (from left to right) the following catego- 
ries: 
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• Slot: the slot number on the chassis occupied by 
the module 

• ,SMB1, SMB10: whether the module can be 
reached via one or both of the SMBs and which is 
preferred s 

• IP: the IP address of the module 

• MAC: the MAC address of the module 

• Other Stuff: other information regarding the module 
such as CPU status, CPU profile, module type. etc. 

10 

Each module (50. 52, 54) builds its own slot table. Each 
module monitors the SMB for messages from other 
modules in order to determine: 

• The presence or absence of a nuKlule is 
The abirity to corhmuriicate with a module over the 
SMB1 

The ability to communicate with a module over the 
SMB10 

• The current status, profile, type, etc., information for so 
other modules 

[0039] Discovery only maintains the "current state" 
__jottheLjchassis. .Maattempt is made to maintain any hisr. 
torical information about the chassis slots. 25 

2.2 Resource Discovery 

[0040] Once a nxxJute is discovered and entered 
into the slot table, the module may be polled for informa- 30 
tion about its resources, such as: 



CPUs (type, speed, utilization) 
Memories (type, size, memory consumed) 
Interfaces (type, speed) 



35 



40 



45 



2.3 Application Discovery 

[0041] Once a module is discovered and entered 
into the slot table, the module may be polled for informa- 
tion about its applications, such as: 

• Application list 

- Type (Distributed or Nondistributed) 

- Status (Enabled, Disabled, Standby) 

3. 'Chassis Election 



[0042] Certain applications need to be supported 
by the chassis, but can be executed on any module so 
(e.g., the distributed chassis agent). At start-up or after 
. _a system change (module failure/removal ietc.)..an elec- 
tion process is required to discover the best location(s) 
on which to run the chassis application(s). The decision 
on where to locate an application (i.e., which module) ss 
within the chassis is based on the following: 



• Current Applications 

• Current Profile (I.e.. CPU's current processing load) 
Module Type 

Slot Number 

[0043] Each application may have its own set of 
instructions for selecting the best location for execution. 
The election instructions are performed by each nrKxJule 
using the data found in its slot table. As each module 
has the same view of the chassis, each election process 
will anive at the same result. In the event of a tie (two 
modules with exactly the same resources), then the 
module with the lower slot number may be chosen (or 
some other criteria used to resolve the tie). The module 
selected will issue an unsolicited message (application 
discovery) reflecting the new status of its application list. 

4. Chassis Agent Access 

[0044] The "chassis agent" is the software that 
allows the networking chassis to be managed as a sin- 
gle system. It is accessed via the network address 
known as the "chassis address." As communications 
withihejchassis. ate.performed .using, multiaccess net- 
works like Ethernet, the chassis must also have a data- 
link address (or "MAC address"). The chassis address 
Is a combination of its IP network and MAC address, 
and is referred to as the chassis IP/MAC address. The 
module acting as the DCA listens for packets having the 
chassis IP/MAC address. 

[0045] The software may run on one or more mod- 
ules within the chassis, but is always accessed via the 
same chassis address. Tlie software is not dependent 
on any one module to perform its function. Each module 
may also have its own network address known as an "IP 
address." Each module must have a data link address 
known as a "MAC address." The chassis agent, regard- 
less of where (on which module) it resides, always uses 
the same chassis IP/MAC address. 
[0046] Packets destined for the Distributed Chassis 
Agent DCA (i.e., packets using the chassis IP/MAC 
address as the destination address) may arrive at the 
chassis via any one (or more) of its front panel ports 
(see ports 25, 27, 29 in Fig. 2), or in the case of the 
present implementation, it may also arrive via the 
SMB.10, as -the-SMBIO is externalized. The packet is 
terminated (from the network point of view) at the entry 
point to the chassis. The module terminating the packet 
has two choices after it has terminated a packet des- 
tined to the DCA: 

...a) .lt..may.sei:vice.the.packelJtself .(Le. act as the 
DCA) 

or 

b) It may fonward the packet to another module for 
service. 



Module's Available Resources 



[0047] The present implementation allows the 
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-8MB10 common network to be accessed froiifi outside 
the chassis. The SMB10 may be used by a network 
management station (NMS) as a channel on which to 
manage the chassis. In the event that a NMS Is located 
on the SMB10. a single module Is elected to act as the 
DCA as all modules will receive packets destined to the 
DCA (i.e.. the SMB1 0 Is a multiaccess network). 

5. MIB Distribution 

[0048] The DCA uses MIBs to gather information 
about the chassis and to effect control on the chassis. A 
MIB is a collection of managed objects (MOs) organized 
-inta a -namlng-(MIB) 4ree-with~each^obieGt having a 
unique name or identifier within the tree. The identifier is 
known as an OID or Object IDentifier In order for the 
DCA to operate as a single entity across all the modules 
in the chassis, ail the MIBs supported by the chassis 
must be distributed across all the modules. 

5.1 MIB Tree 

10049] The MIB tree is distributed across all mod- 
ules within the chassis. The data contained within the 
distributed MIB is not fully distributed, rather each mod- 
ule maintains some of the data locally and fetches the 
rest from the remote modules The data within a distrib* 

. uted MIB can be broken down Into the following types: 

• Local Data 
. • Remote Data 

. [0050] The MIB tree contains data that is main- 
tained locally and pointers to remote data (pointers to 
data on other modules). 

5.2 Distributed Managed Objects 

[0051] To implement a distributed MIB, a remote 
registration process is needed. In this remote registra- 
tion process, as illustrated in Fig. 6, every registering 
module or entity 72, 74. 76, 78 in the chassis registers 
under a particular branch (OID) on every other entity, as 
well as locally. 

, [0052] The same managed object MO (70) appears 
in each MIB object 73. 75, 77, 79, respectively, under 
the same branch. Remote or local access to the man- 
aged object is transparent to SNMP operation. A SET, 
GET or GETNEXT operation acts as if the remotely reg- 
istered object were local. 

' [0053] To resolve "a SNMP operatibh on the MIB 
object, the SNMP agent searches the MIB (via the MIB 
object) and finds the MO registered for the OID in the 
operation. Once the MO is found, the MO's member 
function corresponding to the particular operation (GET, 
GETNEXT SET) is called. Before distributed MO's, this 
was a "local" procedure call, meaning that ail the soft- 
ware code that ran as a result of this call was local to 



- this- processor (in local memory).-Now- with distributed 
MO's. this is not the case. If a SNMP operation resolves 
to an operation on a remote MO, a MORPC (Managed 
Object Remote Procedure Call) will be performed. Rgs. 
5 7-8 depict this situation, where it is assumed that the 
MO has been registered successfully with all chassis 
entities. 

[0054] The above<lesaibed type of registration is 
not limited to leaf objects. Table objects, may also be 
10 registered in this manner. 

5.3 Distributed Managed Object RPCs 

40055] As^discussed^in4he>previous-sectionrnfian- 

15 aged objects can be distributed across multiple entities 
through the use of MORPCs. There are six MORPCs 
that can be generated by an SNMP agent: REGISTER, 
UNREGISTER, GET GETNEXT SETVALIDATE and 
SET A response packet for MORPC is generated by the 
20 MORPC "server" on the remote side of a call. This is 
completely analogous to a return value for a local MO 
call and is illustrated in Fig. 8. 
[0056]" MORPC can be implemented over any 
transport layer protocol. The only change would be In 
26 the address field of the MIBNode object (indicating the 
remote address of the managed object). The present 
implementation uses UDP, which is part of the TCP/IP 
protocol suite. 

[0057] MORPC REGISTER operations occur with 
30 all chassis entities when a MO registers as a distributed 
MO. Registration is a guaranteed operation. An MO 
cannot be partially registered (i e- registered with a 
subset of chassis entities). If a chassis entity becomes 
active after a MO has registered, the MO (or set of MOs) 
35 is registered with it during the entity's start-up (module 
discovery). 

[0058] MORPC UNREGISTER operations occur 
with all chassis entities when a distributed MO unregis- 
ters. The unregister operation is also guaranteed. An 

40 MO cannot be partially unregistered. 

[0059] MORPC GET, GETNEXT, SET, and 
SETVALIDATE are not guaranteed operations. If they 
fail after a specified time-out period, the entire SNMP 
packet is dropped. 

45 [0060] Fig. 7 shows generally four chassis modules 
or entities 100, 102. 104, IDS. MIB object 101 is regis- 
tered locally on module 100. and remotely as MIB object 
103. 105, 107 on modules 102, 104, 106, respectively. 
Managed object (MO) 1 10 is maintained locally on mod- 

50 ule 100. A GET operation 1 1 1 on module 100 finds the 
MO 110 locally, and issues a local call procedure (local 
get 120) to resolve the operation. In contrast, a SET 
operation 112 received on module 102. finds the MO 
110 located remotely and issues a remote procedure 

55 call (set RPC 122) to resolve the operation. Similarly, 
GET operation 113 received on module 104 is resolved 
via a remote procedure call (get RPC 124), and GET- 
NEXT operation 114 on module 106 is resolved as a 
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remote procedure call (getnext RPC 126). 
[0061] Rg. 8 illustrates more specifically the 
method of local and remote retrieval and call process- 
ing. Illustrated on the right, an SNMP operation is 
received by SNMP agent 1 42 in chassis entity 1 40. The 5 
agent locates a remote MIBNode 146 in MIB tree 144 
and initiates a remote operation via MORPC client 148. 
Then MORPC client 148 issues a call to MORPC server 
158 on chassis entity 150 where the managed object 
160 is maintained. The MORPC server 158 retrieves io 
the managed object 160 and sends a MORPC response 
to MORPC client 148. which sends the return values 
from MO 160 back to SNMP agent 142. In the case (on 
the left) of a local SNMP operation, SNMP agent 152 
discovers the local MIB Node 156 in the MIB tre e 154, is 
and retrieves the MO 160 locally on chassis entity~150. 
The return values are sent to SNMP agent 152 without 
requiring utilization of the MORPC server. 
[0062] The present invention is not limited to the 
allocation of management functions across the chassis, 20 
but may be utilized to allocate any type of application . 
across one or more modules in the chassis. 
[0063J The present invention is particularly useful in ' 
combination with tiie subject matter disclosed in two 
copending and commonly-owned applications: 26 

• US. Serial No. 08/188.238 filed January 28. 1994. 
entitled "Network Having Secure Fast Packet 
Switching And Guaranteed Quality Of Service", by 
Kurt Dobbins etal.; and 30 

• U.S. Serial No. 08/188,033 filed January 28, 1994, 
entitied "Fault Tolerant System Management Bus 
Architecture", by Brendan Fee et al. 

which are each hereby incorporated by reference in 3S 
their entirety 

[0064] While there have been shown and described 
several embodiments of the present invention, it will be 
obvious to tiiose skilled in the art that various changes 
and modifications may be made therein without depart- 40 
ing from the scope of the invention as defined by the 
appending claims. 

Claims 

46 

1. A method of network managing, comprising steps 
of 



packets having the agent address. 

3. The method of claim 1 or 2. wherein the network 
modules are disposed in slots of a chassis and the 
application Is a network management application 
which enables the chassis to be managed as a 
whole. 

4. The method of any of the preceding daim, wherein 

each network module exchanges module infor- 
mation which includes one or more of 
resources of tiie respective network module 
and applications of the respective network 

module, arid _ 

each network module elected based on tiie 
module information, which of the network mod- 
ules will execute tiie distributed application. 



providing a plurality of network modules exe- 

-cuting adistributed application; and 

providing a single agent address for accessing 
the distributed application; 
wherein the agent address is a combination of 
a chassis IP network address and a chassis 
MAC address. 

2. The method of claim 1 , wherein each network mod- 
ule executing the distributed application listens for 



8 



EP 1 014 621 A2 



MECHANICAL 
ENCLOSURE 
12- 




NETWORKING 
MODULES 
14 



BACKPLANE 

16- 



POWER 
SUPPLY 

te 



NETWORKING, 
CHASSIS 

to 



Fig. 1 



FRONT PANEL PORTS FRONT PANEL PORTS FRONT PANEL PORTS 
, 25y 27^ 29^ 




m 




24^ 
MODULE 1 



t9: 



CPU 

—7- 
24A 



MODULE 2 



CPU 



2N 



T 
26A 



22. 









MODULE 3 




CPU 




21 


— H 

, 28A 





BACKPLANE 8 BACKPLANE CONNECTIONS-^ 20 



10 



7^ 



Fig. 2 



EP 1014 621 A2 



































MODULE i 




MODULE 2 




MODULES 




MODULE 4 
35^ 




MODULES 
36^ 


.SMB1 












































—COMMON NET\WORK(SMB^YSTEM MANAGEMENT BUS)*^ 

30 


^SMBIO 



F/g,3 



NORMAL 
IP PACKETS ENCAPSULATED 
FOR ETHERNET 
43 \ 



TCP/IP 
PROTOCOL 
STACK 



40 



DA 


SA 


0800 


IP PACKET 




IhfTERNALLY ADDRESSED 
IP PACKETS ENCAPSULATED 
FOR ETHERNET 



DA 


SA 


0800 


IP FWCKET 




Fig.4 



10 




11 



EP 1 014 621 A2 



CHASSIS 

ENirrv 


CHASSIS 
ENTITY 


CHASSIS 
ENTITY 


CHASSIS 
ENTHTY 


( MIB OBJECT ) 
/ 73^ 

7(7^ 


(MIB object) 

/ ^^^^ 


( MIB OBJECT ) 


( MIB OBJECT ) 
79 



Fig.6 



SNMPGET 



SNMP SET 



SNMPGET 



SNMP 6ETNEXT 
-113 



CHASSIS 
ENTITY 

jgo^ 


CHASSIS 
ENTITY 

102^ 


CHASSIS 
ENTfTY 
104. 


CHASSIS 
ENTITY 
106. 


( MIB OBJECT ) 
L 101-^ 

110 


( MIB OBJECT ) 

X SET RPC ^ 
122^^ 


( MIB OBJECT ) 

105-> 

"^GET RPC ^ 
124^^^ 


( MIB object) 
^y(^t07'' 

GETNEXT RPC 
126 



Fig. 7 



12 



EP 1014 621 A2 



SNMP OPERATION ON CHASSIS ENTTTY CHASIS ENTTTY SNMP OPERATION ON 



LOCAL MIBNode 



152' 



150 



SNMP 
AGENT 



m^di MIB OBJECT ^ 



LOCAL OP 
160 



MIBNode 
LOCAL 



J) 



RETURN 
VALUES ^/3s 



MORPG 
SERVER 



140 



REMOTH MIBNode 



SAME 
- OID - 
BRANCH 



i 



SNMP 
AGENT 



'142 



^ MIS OBJECT y — 144 




MIBNode 
REMOTE 



146 



MORPC 
CLIENT 




143 REMOTE OB- 



MORPC 



MORPC RESPONSE 



RETURN 
VALUES 



F/g.d 



13 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(88) Date of publication A3: 

18.07.2001 Bulletin 2001/29 

(43) Date of publication A2: 

28.06.2000 Bulletin 2000/26 

(2^) Application number: 99120908.1 

(22) Date of filing: 26.01.1995 



(11) EP1 014 621 A3 

EUROPEAN PATENT APPLICATION 

(51) lntCI.7: H04L 12/24 



(84) Designated Contracting States: 

AT BE CH DE DK ES FR GB GR IE it LI LU iVIC NL 
PTSE 

Designated Extension States: 
LTSI 

(30) Priority: 28.01.1994 US 187856 



(62) Document number(s) of the earlier applicatlon(s) in 
accordance with Art. 76 EPC: 
95908730.5/0 741 938 

(71 ) Applicant: CABLETRON SYSTEMS, INC. 
Rochester, NH 03867 (US) 



(72) Inventors: 

• Pee, Brendan 
Nashua, NH 03036 (US) 

• Dobbins, Kurt 
Bedford, NH 03102 (US) 

• Arneson, David 
Bow, NH 03304 (US) 

• Mullaney,Pat ^ 

Nashua, New Hampshire 03060 (US) 

(74) Representative: HOPPMANN - EITLE 
Patent- und RechtsanwSlte 
Arabellastrasse 4 
81925 MQnchen(DE) 



(54) Method of network managing 

(57) A method of network managing comprises 
steps of providing a plurality of network modules exe- 
cuting a distributed application; and providing a single 



agent address for accessing the distributed application; 
wherein the agent address Is a combination of a chassis 
IP network address and a chassis MAC address. 




Printed by Jouve, 75001 PARIS (FR) 



EP 1 014 621 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 99 12 0908 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



CHatlon of document wlh Indication, where appropriate. 
ot relevant passages 



US 5 226 120 A (CHOWDHURY SHABBIR A ET 
AL) 6 July 1993 (1993-07-06) 

* abstract; figure 10 * 

* column 1, line 50 - line 60 ♦ 

* column 13, line 25 - line 60 * 

* column 14, line 57 - Itne 67 * 

* column 15, line 43 - line 46 * 

* column 17, line 5 - line 7 ♦ 

* claim 14 * 

EP 0 384 339 A (DIGITAL EQUIPMENT CORP) 
29 August 1990 (1990-08-29) 

* abstract * 

WO 92 19054 A (CONCORD COMMUNICATIONS INC) 
29 October 1992 (1992-10-29) 

* abstract; figures 3,5,36,37 * 

* page 3, line 3 - line 27 ♦ 

* page 5, line 22 - page 6, line 3 * 

* page 7, line 12 - line 21 * 

* page 18, line 24 - page 20, line 25 ♦ 

DEERING, S. E.: ''SIP: Simple Internet 
Protocol " 

IEEE NETWORK, 'Online! 

vol. 7, no. 3, May 1993 (1993-05), pages 

16-28, XP002167397 

ISSN: 0890-8044 

Retrieved from the Internet: 

<URL:www. ieee.org> 

* retrieved on 2001-05-15! 

* page 16, left-hand column * 

* page 18, left-hand column, paragraph 3 - 
page 21, left-hand column, paragraph 1; 
figure 3 ♦ 



1-4 



The present search report has been dravm up tor all claims 



Relevant 
to cteUm 



1-4 



1-4 



CLASSIFICATION OF IVIE 

APPUcATiON om.a.7) 



H04L12/Z4 



-nECHNICAL RELDS 
SEARCHED (lnt.Gt.7) 



H04L 



Place ol searc^ 

MUNICH 



Date of oomptetton of ttie learBti 



16 May 2001 



Exarnlrwr 

Huber, 0 



CATEGORY OF CITED DOCUMENTS 

X ; particularly -elevant It taken alone 

Y : particularly 'elevant If combined wHh another 

documer t of the same categoiy 
A : technological background 
O : non-writter dlsdoaure 
P : intermecKale document 



T : tneory or principle undertying tt'e Invention 
E : earfiBf patent document but published on, or 

afte- the filing date 
D : document cited in the application 
L . document died for otier reasons 

& : rnerrber of the same patent tanlly, corresponding 
docjineni 



2 



EP 1 014 621 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 

ON EUROPEAN PATENT APPLICATION NO. EP 99 12 0908 



This annex lists the patent family members relating lo the patent documents cited In the above-^nentioned European search report. 
The members are as contained in the European Patent Office EDP file on 

The European Patent Office lis in no way liable for these particulars which are merely given for the purpose of Information. 

16-05-2001 



Patent document 
cited in search report 



Publication 



Patent family 
member(s). 



Publication 
date 



US 5226120 



EP 0384339 



A 
A 



06-07-1993 
29-08-1990 



US 

AT 
AU 
AU 
AU 
AU 
CA 
DE 
DE 
JP 
US 



5606664 A 



25-02-1997 



151183 
611605 
4996190 
630291 
7603391 
2010762 
69030340 
69030340 
3116262 
5.341477 



WO 9219054 



29-10-1992 



US 



6115393 A 



15-04- 
13-06- 
13-09- 

22- 10- 
15-08- 
24-08- 
07-05- 
20-11- 
17-05- 

23- 08- 



1997 
1991 
1990 
1992 
1991 
1990 
1997 
1997 
1991 
1994 



05-09-2000 



i For more details about this annex :see Official Journal of the European Patent Office, No. 12/82 



3 



